home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1511 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.1 KB
  1. Subject: Re: GEMDOS re-entrancy
  2. Date: Thu, 2 Jun 94 23:45:16 CDT
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <m0q8FaG-0000jgC@sdf.lonestar.org>; from "Evan K. Langlois" at May 30, 94 5:13 pm
  5. Message-Id: <9406022145.AA00165@jelal.north.de>
  6.  
  7. Evan K. Langlois writes:
  8.  
  9. > ========================================================================
  10. > Yes, that is it, indeed. But everybody sees the necessity to have such a
  11. > TOSFS, but nobody develops it :(
  12. > ========================================================================
  13. > 
  14. > Why not have TOSFS lock the system, but not other drivers?
  15.  
  16.  this is what would happen with the filesystem-multithreaded flag...
  17. and you could still use the CPU when Rwabs called from GEMDOS goes to
  18. sleep.
  19.  
  20. > ========================================================================
  21. > But maybe it is good, that there is still no code around, so we could wait
  22. > for the chicago fs and implement it then all-in-one...
  23. > ========================================================================
  24.  
  25.  you people think too much peecee :)  i would be more intrested in what
  26. the BSD 4.4 filesystem improvements are for example...
  27.  
  28. > ========================================================================
  29. > That is what I suggested a long time ago, but as far as I know AHDI does
  30. > not use it. It just sets it for every access, but never checks it before
  31. > doing so :(
  32. > ========================================================================
  33. > 
  34. > Don't we need a new disk driver anyway that won't block the system?  I thought
  35. > that once we called AHDI, MiNt would loose control.  Someone said they had
  36. > SCSI code.  I'd be in favor of hacking up a new driver.
  37.  
  38.  claus? :)
  39. > 
  40. > ========================================================================
  41. > Well, yes and no. The floppy data transfer is done via DMA, the same DMA
  42. > channel as the ACSI HD interface uses. So it will lock out that hard disk
  43. > access. But on a TT, there should be a chance that there can be floppy
  44. > transfer at the same time as SCSI transfer... provided that there is the
  45. > software to support it.
  46. > ========================================================================
  47. > 
  48. > That would be nice.  To be formatting a floppy, saving data to the SCSI
  49. > drive, and still be able to do serial IO (Zmodem could save a block and
  50. > read in another at once - who needs flow control?).  And you could be
  51. > doing a ray-trace too :-)   I guess I'm just dreaming.  
  52.  
  53.  btw here is a reason why TT SCSI should not use flock, because that
  54. would more or less block doing ACSI/floppy IO at the same time...
  55. > 
  56. > So, we replace AHDI with a real SCSI/ACSI driver and implement a new TOSFS.
  57.  
  58.  is tosfs really that important?  i mean who now needs it for more than
  59. data exchange (floppies) and the boot filesystem?
  60.  
  61. > some other minor hacks (the SCSI device driver should handle
  62. > putting processes on the wait queue and such).
  63.  
  64.  ACSI ofcourse too.
  65.  
  66.  cheers
  67.     Juergen
  68. -- 
  69. J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
  70.                                 ...ohne Gewehr
  71. PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA 
  72.